Instead of just using regular struct lowering for these types, which
results in an incorrect ABI (e.g. returning indirectly), use
`BackendRepr::ScalableVector` which will lower to the correct type and
be passed in registers.

This also enables some simplifications for generating alloca of scalable
vectors and greater re-use of `scalable_vector_parts`.

A LLVM codegen test demonstrating the changed IR this generates is
included in the next commit alongside some intrinsics that make these
tuples usable.

Clang changed to representing tuples of scalable vectors as
structs rather than as wide vectors (that is, scalable vector types
where the `N` part of the `<vscale x N x ty>` type was multiplied by
the number of vectors). rustc mirrored this in the initial implementation
of scalable vectors.

Earlier versions of our patches used the wide vector representation and
our intrinsic patches used the legacy
`llvm.aarch64.sve.tuple.{create,get,set}{2,3,4}` intrinsics for creating
these tuples/getting/setting the vectors, which were only supported
due to LLVM's `AutoUpgrade` pass converting these intrinsics into
`llvm.vector.insert`. `AutoUpgrade` only supports these legacy intrinsics
with the wide vector representation.

With the current struct representation, Clang has special handling in
codegen for generating `insertvalue`/`extractvalue` instructions for
these operations, which must be replicated by rustc's codegen for our
intrinsics to use. This patch implements new intrinsics in
`core::intrinsics::scalable` (mirroring the structure of
`core::intrinsics::simd`) which rustc lowers to the appropriate
`insertvalue`/`extractvalue` instructions.

Generate debuginfo for scalable vectors, following the structure that
Clang generates for scalable vectors.

Abstract over the existing `simd_cast` intrinsic to implement a new
`sve_cast` intrinsic - this is better than allowing scalable vectors to
be used with all of the generic `simd_*` intrinsics.

PR rust-lang#154634 recently renamed many type parameters that impl
`HashStableContext` as `Hcx`. It missed a few that are named `HirCtx`.
This commit renames them.

They're in multiple sections with no rhyme or reason.

`derive(HashStable_Generic)` generates impls like this:
```
impl<__CTX> HashStable<__CTX> for ExpnKind
where
    __CTX: crate::HashStableContext
{
    fn hash_stable(&self, hcx : &mut __CTX, __hasher: &mut StableHasher) {
        ...
    }
}
```
This is used for crates that are upstream of `rustc_middle`.

The `crate::HashStableContext` bound means every crate that uses
`derive(HashStable_Generic)` must provide (or import) a trait
`HashStableContext` which `rustc_middle` then impls. In `rustc_span`
this trait is sensible, with three methods. In other crates, this trait
is empty, and there is the following trait hierarchy:
```
rustc_session::HashStableContext
  |              |
  |   rustc_hir::HashStableContext
  |         /                   \
rustc_ast::HashStableContext   rustc_abi::HashStableContext
  |
rustc_span::HashStableContext
```
All very strange and unnecessary. This commit changes
`derive(HashStable_Generic)` to use `rustc_span::HashStableContext`
instead of `crate::HashStableContext`. This eliminates the need for all
the empty `HashStableContext` traits and impls. Much better.

This annotates the `Arc` type with the diagnostic attribute
`#[diagnostic::on_move]`. Now when a moved `Arc` is borrowed,
a suggestion to clone it is made, with a label explaining why.

…er of arguments

…attrs` function

…_attrs` function

…y_macro_source` function

…_macro` function

…middle_region` function

…region_outlives_predicate` function

…proc_macro` function

…f_id_and_parts` function

…field_with_def_id` function

…cBound` methods

…bound_vars` function

…ctions